Status of this Memo

This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on November 11, 2003.

Copyright Notice

Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

The Generic Transport Protocol for Signaling (GIMPS) provides a generic transport service to set up, modify and tear down signaling state in signaling nodes.

Table of Contents

1.  Introduction
2.  Overview of Operations
3.  Message Format
4.  Security Considerations
4.1  Confidentiality
4.2  Integrity
4.3  Authentication
§  Authors' Addresses
§  Normative References
§  Informative References
A.  Acknowledgements
§  Intellectual Property and Copyright Statements

1. Introduction

Signaling involves the setting up, modifying and tearing down of state in network elements. GIMPS maintains state along the data path of a data session [ref]. Examples of such state include network resource allotments (for "resource reservation"), a firewall configuration and active network state. Each of these applications is considered a signaling service that uses the transport service defined in this document. Different applications may make use of different services provided by GTSP.

Signaling establishes state sessions, which have a defined beginning and end. While the beginning of a session is always established by explicit protocol action, a session may end by a signaling teardown message or a time-out ("soft state").

Not every router along the datapath needs to be involved in the signaling session. Indeed, it appears likely that only a subset of nodes will be aware of any given signaling application.

A related set of applications visits nodes along the data path, to discover path properties, for example, but does not leave any state behind. This can be considered a signaling application that establishes and tears down state in the same message and thus is within the scope of this effort.

GIMPS is not just an end-to-end transport mechanism for a higher-layer signaling. An example of the latter would be SCTP, to transport ISUP between two nodes. In GIMPS, there are almost always more than two participants in a signaling session, as there is not much point in using a signaling protocol just to communicate between two end points.

GIMPS is not meant to manage application-layer state, but rather to manage state related to data transport. Thus, GIMPS messages need to follow the path of the data. In that crucial respect, it differs from application signaling protocols such as the control component of ftp, SIP and RTSP.

A more detailed discussion can be found in the Next Steps in Signaling Framework[1].

GIMPS is designed to support the largest range of signaling applications. While a number of such applications have been identified, it appears likely that new applications will emerge. (This was the case after the development of RSVP, for example.)

End systems can change network attachment point and network address during a session.

Signaling often occurs before an application such as an IP telephone conversation can commence, so that any signaling delay becomes noticeable to the application. Signaling delays are incurred by the delay in finding signaling nodes along the path (peer discovery), in retransmitting lost signaling messages and in setting up security associations between nodes, among other factors.

GIMPS supports both IPv4 and IPv6.

GIMPS can operate over any message or stream-oriented transport layer, including UDP, TCP and SCTP. [TBD: support raw IP?] Messages sent over protocols that do not offer a native fragmentation service, such as UDP, are strictly limited in size and rate to avoid network congestion problems. [TBD: The 'transport' terminology really gets confusing. Maybe we should rename the NTLP as a messaging layer.]

The end systems in a session may not be capable of handling either the signaling transport or the application.

The signaling transport mechanism has to accomplish two fundamental objectives:

1. Discover the set of nodes along the path from the data sender to the receiver (peer discovery);
2. Deliver signaling information along this chain of nodes.

In many cases, signaling information needs to be delivered reliably between the signaling initiator and responder. Some applications may implement their own reliability mechanism, but experience with RSVP has shown[2] that relying on soft-state refreshes itself may yield unsatisfactory performance if signaling messages are lost even occasionally.

2. Overview of Operations

GIMPS does not attempt to replicate a full-featured transport protocol such as TCP or SCTP. It does not support congestion control, message fragmentation, flow control, acknowledgment windows and selective acknowledgements (SACK). Thus, its "raw" efficiency in more demanding network conditions is likely to be low. Instead, GIMPS leverages the continuing advances in transport protocols such as TCP and SCTP for messages where these features are useful.

Each node maintains a forwarding state table that includes

Cryptographically random and globally unique session identifier

The destination address of the message, contained in the GIMPS message. (This is not necessarily the IP address in the message.)

Generally, each session will have at least two entries, one for the initiator-to-responder direction, the other for the responder-to-initiator message flow. If the end points are mobile, additional entries may be added. The forwarding state table entries are discarded after the Rediscovery Period (RDP).

For efficiency reasons, GIMPS combines two modes, a "fast" mode and a "bulk" mode. On receiving a GIMPS message, a node performs the following operations. (It does not matter whether the message arrived over a reliable or unreliable lower-layer transport mechanism.)

1. The GIMPS node compares the GIMPS destination network address (not the lower-layer network address) to its own address. If it matches one of its addresses, the message has arrived and is passed to the signaling application for further processing.
2. The GIMPS node inspects the session identifier in the incoming message and determines if it matches an existing session. It also compares the responder address to the responder contained in the state record. If both match and the rediscovery period (RDP) has not expired, the node forwards the message to the next node on the existing transport and security association (e.g., TCP connection, TLS session, or IPsec session). If there is no known next-hop, the node checks the message size and compares it against the maximum datagram size (MDS, below), a global constant. (Since the message may be forwarded across multiple hops, knowledge of the link MTU size is not sufficient.) If the message size falls below MDS, the message is forwarded towards the network address contained in the GIMPS message, i.e., the current responder and marked with an IP router-alert option that causes it to be intercepted by the next GIMPS-capable node. The GIMPS message uses the source address of this node, to facilitate the discovery of network problems and to allow the next node to return a confirmation message (see below). If the message size exceeds MDS, the node constructs a discovery message that has the same message type, session identifier and client-layer identifier as the GIMPS message triggering it. It then transmits it in the same manner described in the last paragraph. Messages that arrive during the discovery phase can be queued or also sent forth as discovery messages. Messages that exceed MDS in size MUST be queued. To avoid network congestion, a node MUST NOT have more than one message outstanding at any given time. If no response is received within the retransmission interval (RTI, default 1 s), the message is retransmitted. (No instance identifier is used since round-trip time estimation is unlikely to be successful.) The node records the transport association or network address of the previous hop. This information is used for messages that are sent by the responder to the initiator.
3. When the next node receives a GIMPS message with the 'response-requested' flag, it sends a response to the IP address of that message, confirming receipt. The response uses the source address of the next-hop node.
4. When a message arrives, the node records the transport association that the message arrived on in the state table.
5. When a node receives a response, it determines if there is an existing transport/security association with that node. If not, it establishes such a connection. (The response indicates the types of security and transport mechanisms that are available, e.g., TLS-over-SCTP.) In either case, the GIMPS node sends any queued messages on that new or existing association.

3. Message Format

The following items are mandatory for each message:

Initiator address:

The current network (IPv4 or IPv6) address of the initiator of the signaling session. The initiator may change during a session, e.g., if the initiator moves to a different network.

Responder address:

The current network (IPv4 or IPv6) address of the destination (responder) of the signaling session. The responder may change during a session, e.g., if the initiator moves to a different network.

Session identifier:

The GIMPS session identifier is a long, cryptographically random identifier chosen by the initiator. The length is TBD, but 128 bits should be more than sufficient to make the probability of collisions orders of magnitude lower than other failure reasons.

Hop counter:

A hop counter prevents a message from looping indefinitely. (Since messages may get translated between different lower-layer transport protocols, the IP hop count cannot be relied upon.)

Service identifier:

The service identifier [TBD: application identifier?] describes the signaling application, such as resource reservation or firewall control.

Message identifier:

A four-octet message counter, used to associate messages with their confirmations.

Flags:

A number of flags define protocol operations, such as "confirmation requested" (hop-by-hop confirmation message).

Message type:

The operation code defines three operations:

establish:

Establish or refresh a session.

refresh:

Refresh only if the session exists [TBD: is this useful?]

failure:

A message-layer failure occurred, such as a mis-formatted message or an authentication or integrity check failure.

teardown:

Tear down.

confirmation:

Confirms the receipt of an earlier message, with the message number included.

The following items are optional:

Lifetime:

The lifetime of a session in the absence of refreshes, measured in seconds. Defaults to 30 seconds. Cannot be changed by any intermediate node.

Confirm:

Confirms receipt of a message. [May not be needed if 'confirmation' automatically means that the message number is confirmed.]

The message content is encoded in an RSVP-style format, i.e., consisting of type-length-value (TLV) objects. If transported on a bytestream-oriented protocol, the whole message is preceded by a four-octet length field.

4. Security Considerations

4.1 Confidentiality

GIMPS can use lower-layer transport functionality, such as TLS or IPsec, to ensure message confidentiality.

4.2 Integrity

GIMPS can use lower-layer transport functionality, such as TLS or IPsec, to ensure message confidentiality.

4.3 Authentication

GIMPS nodes can assure themselves of the identity of the next hop via the the lower-layer transport functionality. However, with discovery, there is no effective way to know what is the legitimate next hop as opposed to an impostor.

Normative References

Informative References

Authors' Addresses

Appendix A. Acknowledgements

Your name here.

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.

Full Copyright Statement

Copyright (C) The Internet Society (2003). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society.